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Briefing  Outline 


•  Background 

•  Review  of  CCPDS-R  Architecture 

•  Characteristics  and  Assessment  of 

Software  Development  Approach 

•  Areas  for  Improvement 

•  Conclusions 


The  briefing  is  organized  into  five  parts.  To  provide  context,  several 
vugraphs  will  be  used  to  describe  the  background  of  the  Command 
Center  Processing  and  Display  System  -  Replacement  (CCPDS-R) 
Program  and  to  review  the  CCPDS-R  hardware  and  software 
architecture.  The  bulk  of  the  briefing  will  characterize  and  assess  the 
CCPDS-R  software  development  approach.  This  assessment  will  be 
followed  by  a  listing  of  areas  for  improvement,  and  conclusions. 
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Briefing  Purpose 


•  To  describe  the  CCPDS-R  software 

development  approach 

and 

•  Assess  benefits  and  limitations  based 

on  experience  to  date 


The  briefing  has  two  main  purposes.  The  first  purpose  is  to  describe  the 
approach,  and  the  second  is  to  assess  the  benefits  and  limitations  based 
on  experience  to  date. 
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CCPDS-R  System  Overview 


CHEYENNE  MT.  AFB 


MISSILE  WARNINGS 


MITRE 

The  CCPDS-R  consists  of  three  subsystems.  The  Ballistic  Missile 
Warning  Subsystem  will  be  located  at  Cheyenne  Mountain  and  at  Offutt 
AFB  in  the  Offutt  Processing  and  Correlation  Center.  The  facility  at 
Offutt  AFB  is  intended  as  a  backup  to  the  prime  missile  warning  facility  at 
Cheyenne  Mountain.  The  second  CCPDS-R  subsystem  consists  of 
remote  missile  warning  displays  to  be  located  throughout  the  world, 
principally  at  the  National  Military  Command  Center  (NMCC)  and  its 
alternate,  and  at  the  command  centers  of  the  various  nuclear-capable 
theater  commanders.  The  third  CCPDS-R  subsystem  is  the  Strategic  Air 
Command  (SAC)  Bomber  Force  Management/Survival  Subsystem  to  be 
located  at  SAC  Headquarters.  Its  mission  is  to  manage  and  reconstitute 
the  SAC  bomber  fleet  in  response  to  a  ballistic  missile  attack  on  either 
the  United  States  or  other  areas  of  interest. 
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Operational  Objectives 


•  Common  displays  at  all  user  locations 

•  Direct  sensor  data  to  users 

•  Throughput  and  response  time  for  twice  predicted 

load " 

•  Functionally  improved  and  more  accurate 

algorithms 

•  Color  graphic  and  tabular  displays 

•  State-of-the-art  processing  and  display  for 

maintainability 

•  Fail-safe  missile  warning  backup  for  survivability 

•  Ada  implementation  for  maintainability  and 

reusability 


The  operational  objectives  of  the  CCPDS-R  are  listed  here  for  reference. 
Except  for  the  last  item  dealing  with  Ada,  these  will  not  be  addressed 
further  in  this  briefing.  With  regard  to  the  Ada  computer  programming 
language,  it  should  be  mentioned  that  all  TRW-developed  code  for  the 
CCPDS-R  is  being  written  in  Ada.  Ada  is  being  used  to  enhance  the 
maintainability  and  reusability  of  the  CCPDS-R  software.  More  will  be 
said  on  these  topics  later  in  this  presentation. 
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Missile  Warning  Processing  Functions 


I - T 


PROCESSING 


MITRE 


The  Missile  Warning  Subsystem  is  the  first  of  the  three  CCPDS-R 
subsystems  to  be  implemented.  The  heart  of  the  Missile  Warning 
Subsystem  functionality  consists  of  a  processing  thread  involving 
input/output  message  validation,  threat/non -threat  determination,  and 
display  generation.  This  thread  represents  the  external  interfaces,  the 
missile  warning  algorithms,  and  all  operational  displays.  It  is  the  thread 
that  has  the  strictest  time-critical  requirements  imposed  upon  it,  i.e., 
three  seconds  from  receipt  of  an  external  message  to  display,  and  one 
second  response  time  to  operator  requests  for  displayed  information. 
The  other  functions  indicated  on  the  vugraph  include  performance 
monitoring  and  recovery  processing,  and  several  off-line  functions. 
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Missile  Warning  Subsystem  Architecture 
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The  Missile  Warning  Subsystem  hardware  suite  comes  largely  from  the 
Digital  Equipment  Corporation  (DEC).  The  VAX  8800  Mission  Processor 
is  used  for  communications  and  algorithmic  processing,  the  VAX  3200  is 
used  for  display  processing,  and  the  VAX  8350  Support  Processor  is 
used  for  off-line  functions  and  simulated  message  injection.  The 
software  consists  of  six  Computer  Software  Configuration  Items  (CSC Is) 
for  the  TRW-developed  software,  and  Commercial  Off-the-Shelf  (COTS) 
software  provided  with  the  DEC  hardware  family.  This  software  includes 
VAX  VMS  and  Rdb.  The  size  of  the  TRW  software  for  the  Missile 
Warning  Subsystem  is  337K  source  lines  of  code  (SLOC),  all  written  in 
Ada. 
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Missile  Warning  Subsystem 
Hardware/Software  Hierarchy 


=  10  KSLOC 
“1 

=  190  KSLOC 


=  140  KSLOC 

_J _ 


Hierarchically,  the  TRW-developed  software  has  been  constructed  to 
isolate  DEC  hardware  and  operating  system  (VMS/Starlet) 
dependencies  to  essentially  one  CSCI,  i.e.,  Network  Architecture 
Services  (NAS),  and  within  that  CSCI  to  about  10K  SLOC.  TRW  has 
also  isolated  the  more  difficult  features  of  Ada  such  as  tasking  and 
rendezvous  to  the  NAS  CSCI  which  is  about  20K  SLOC.  As  a  result, 
TRW  has  been  able  to  develop  the  applications  software  using  relatively 
inexperienced  Ada  designers  and  coders,  while  limiting  the  need  for 
expert  Ada  professionals  to  a  core  group  of  about  1 0  individuals  who  are 
concerned  with  the  design  and  coding  of  NAS.  Due  to  its  complexity, 
NAS  will  not  be  easy  to  maintain,  but  should  not  require  frequent 
extensive  modification  as  will  the  applications  software  which  can  be 
severely  impacted  by  changes  in  operational  requirements. 
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Software  Architecture  Skeleton  & 
Applications  Software  Relationship 


MITRE 


To  facilitate  the  development  of  the  applications  software,  TRW  devised  a 
top-down  architecture  skeleton  consisting  of  generically  instantiated 
software  for  Node  Managers,  Process  Executives,  and  Task  Executives. 
The  skeleton,  which  was  developed  early  in  the  CCPDS-R  Program, 
implements  a  message-based  design  in  which  processors  (or  nodes) 
communicate  with  other  processors  by  means  of  messages.  A  similar 
scheme  exists  for  VMS  processes  resident  in  a  processor  to  communicate 
with  other  VMS  processes.  Ada  tasks  resident  within  a  process  also 
communicate  with  other  Ada  tasks  by  means  of  messages.  The  forms  of 
communication  are  referred  to  as  Inter-Task  Communications  (ITC)  Level  1 
(Task-to-Task),  Level  2  (Process-to-Process),  and  Level  3  (Node-to-Node). 
The  overhead  associated  with  such  an  architecture,  specially  for 
node-to-node  communications,  is  higher  than  would  be  obtained  using  VMS 
alone.  MITRE  estimates  the  overhead  at  about  30-35  percent  CPU 
utilization  vs.  10-1 5  percent  for  VMS.  However,  the  overhead  penalty  is 
offset  by  the  ease  with  which  applications  software  can  be  added  by  the 
developers  who  need  not  know,  nor  be  concerned  with,  how  Ada  tasks 
communicate  with  other  tasks;  rather,  they  need  only  be  involved  with  the 
design  of  Ada  task  bodies. 
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Software  Architecture  Skeleton 


•  Consists  of  generic  software  instantiated  at  compile  time 
9  Identifies  nodes,  processes,  tasks,  and  task  connections 

(circuits  and  sockets) 

•  Composed  of  network  manager,  node  managers, 

process  executives,  task  executives,  and  a  database 
controlling  inter-task  communications 

•  Encapsulates  difficult  features  of  Ada,  such  as  tasking 

•  Permits  early  integration  with  stubs,  as  appropriate,  and 

step-wise  integration  with  actual  applications  software 
thereafter 

•  Reused  repeatedly  as  applications  are  added 

•  Applications  software  is 

-  Independent  of  DEC  hardware  architecture 

-  Consists  of  logically  interconnected  software  modules 

MITRE 


This  vugraph  summarizes  the  salient  features  of  the  software 
architecture  skeleton.  Instantiation  refers  to  a  process  whereby  software 
operations  are  converted  from  generic  form  through  the  specification  of 
data  types  at  compile  time.  The  skeleton  permits  software  integration  to 
take  place  top-down  with  stubs  used  for  missing  applications.  The 
skeleton  also  provides  a  source  of  early  software  reliability  data  because 
it  is  used  repeatedly  by  each  of  the  developers  throughout  the 
applications  software  development  cycle.  The  skeleton  is  the 
mechanism  by  which  the  applications  software  is  isolated  from  hardware 
and  operating  system  dependencies.  (Note:  Small  portions  of  the  CCO 
CSCI  contain  hardware-dependent  code  for  the  Excelan  and  Simpact 
interfaces.  Likewise,  the  DCO  CSCI  contains  some 
hardware-dependent  code  for  the  Chromatics  display  generator,  and  the 
large-screen  digital  and  video  interface  equipments.) 
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Major  CCPDS-R  Milestones 
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This  next  portion  of  the  briefing  attempts  to  characterize  and  assess  the 
overall  software  development  approach. 

The  first  characteristic  of  importance  is  the  development  schedule. 
CCPDS-R  is  favored  with  a  realistic  schedule  in  which  sufficient  time  has 
been  allocated  between  the  major  review  milestones  for  each  of  the 
three  CCPDS-R  subsystems  to  accomplish  the  work  required.  Although 
each  individual  schedule  is  reasonable,  a  moderate  degree  of  schedule 
overlap  (concurrency)  exists  among  the  three  developments.  This  may 
cause  key  resources  (facilities  and  personnel)  to  be  stretched  too  thin. 
The  first  signs  may  appear  in  late  1989  when  major  activities  on  all  three 
subsystems  will  be  proceeding  in  parallel  for  the  first  time. 
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Months  between  Major  Milestones* 
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OF 
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To  further  highlight  the  reasonableness  of  the  separate  development 
schedules,  the  numbers  of  months  between  major  software  milestones 
were  plotted.  This  chart  shows  that  in  all  instances  at  least  six  months 
have  been  scheduled  between  the  major  milestones  indicated  in  the 
footnote.  The  average  is  9.4  months.  The  average  for  the  design 
phases  (i.e.,  Software  Specification  Review  (SSR)  to  Critical  Design 
Review  (CDR))  of  each  of  the  three  subsystems  is  17.7  months,  and  the 
average  duration  of  the  software  development  phases  (design  through 
test)  is  29.3  months. 
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Software  Staffing* 


MONTHS 
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The  second  characteristic  which  the  CCPDS-R  Program  has  in  its  favor 
is  software  staffing.  The  staff  size  rises  quickly  and  stays  in  the  60  -  80 
range  for  the  bulk  of  the  schedule,  from  contract  award  to  completion  of 
Formal  Qualification  Testing  (FQT)  of  the  third  subsystem.  This  staff 
complement  is  of  manageable  proportions.  It  includes  a  cadre  of  about 
10  Ada  experts  who  are  responsible  for  the  more  difficult  software  (i.e., 
NAS)  and  who  have  been  with  the  NAS  development  from  its  inception 
as  a  TRW  Independent  Research  and  Development  (IR&D)  project  in 
1983  through  the  CCPDS-R  Concept  Development  Phase  (1985  -1986), 
and  since  contract  award  for  the  current  Full-Scale  Development  Phase 
(June  1987).  This  cadre  also  provides  Ada  training  for  the  other 
software  professionals  working  on  the  CCPDS-R  Program. 
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Prototyping  and  Build  Processes 


•  REVIEW  OF  COMPONENT  SPECS 

•  FOCUS  ON  PROGRAM  STRUCTURE 

•  DEMO  ABILITY  TO  COMPILE 


REVIEW  OF  COMPONENT  AND 
UNIT  SPECS  AND  BODIES 

DEMO  PROPER  OPERATION 

MITRE 


The  third  characteristic  and  the  one  that  tends  to  distinguish  the  CCPDS-R 
Program  from  others  is  the  software  prototyping  and  build  process 
culminating  in  functional  capability  demonstrations.  The  prototyping  of 
critical  performance  components  and  the  prototyping  of  the  User-System 
Interface  (USI)  are  enabling  TRW  to  better  define  the  development 
requirements  for  the  software.  The  builds,  of  which  there  are  about  ten, 
are  in  essence  mini-developments,  each  with  top-level  and  detailed  design 
phases,  a  coding  phase,  and  an  integration/test  phase.  Each  build  has  a 
Preliminary  Design  Walkthrough  (PDW)  and  a  Critical  Design  Walkthrough 
(CDW)  in  which  a  specialized  technical  audience  of  about  40  to  50  people, 
including  the  Government,  participates.  Each  build  can  then  be  formally 
demonstrated  to  the  Government  in  accordance  with  an  approved 
Demonstration  Plan  which  includes  pass/fail  criteria.  The  overall  process 
focuses  the  work  on  near-term  products,  visible  to  all,  and  forces  early 
accountability  from  the  developers.  The  functional  contents  of  the 
demonstrations  are  specified  by  the  Government  in  the  Statement  of  Work 
(SOW)  prior  to  contract  award  to  insure  that  the  difficult  parts  of  the  job  are 
accomplished  first  and  to  insure  that  the  builds  are  operationally  useful. 


Prototyping  of  Components 


i 


•  Define  required  inputs  and  outputs 

•  Define  top-level  architecture  (Process  and  Task 
Specifications)  to  achieve  partial  component 
functionality 

•  Define  task-to-task  interfaces 

•  Instantiate  Software  Architecture  Skeleton  (SAS) 

•  Demonstrate  ability  to  compile  critical  components 

used  in  Task  Bodies  at  PDW 

•  Further  define  Task  Bodies  to  achieve  full  component 

functionality 

•  Demonstrate  proper  operation  at  CDW 


MITRE 


The  software  prototyping  is  achieved  in  two  phases.  Prior  to  PDW, 
required  inputs  and  outputs  are  defined,  along  with  process  and  task 
specifications,  and  task-to-task  interfaces.  The  software  architecture 
skeleton  is  instantiated  and  the  critical  software  components  are 
compiled.  After  PDW,  the  task  bodies  are  further  defined.  When  CDW 
is  conducted,  proper  operation  of  the  prototyped  component  is 
demonstrated. 
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Software  Builds 
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Altogether,  there  are  ten  software  builds  currently  defined  for  the  three 
CCPDS-R  subsystems.  The  first  build  for  each  subsystem  contains  the 
foundation  software  (i.e.,  NAS  and  Software  Architecture  Skeleton)  on 
top  of  which  applications  software  may  be  overlaid  in  the  later  builds. 
This  process  of  iteration  is  permitting  TRW  and  the  Government  to 
identify  procedural  problems  (and  differences  in  expectation)  and  to 
resolve  them  early.  The  experience  gained  in  the  first  few  builds  have 
been  and  are  being  applied  to  the  remaining  builds  resulting  in  a  more 
efficient  design,  better  documentation,  and  a  cost-effective  test  process. 


Capability  Demonstrations 
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Seven  capability  demonstrations  are  specified  in  the  CCPDS-R  SOW. 
The  demonstrations  conducted  to  date  have  been  invaluable  in  providing 
concrete  visibility  into  true  development  progress.  Problems  identified  by 
the  demonstrations  have  been  and  are  being  used  to  formulate 
corrective  actions.  The  demonstrations  are  tied  to  formal  reviews,  such 
as  SSR,  Preliminary  Design  Review  (PDR),  or  CDR,  and  to  the  award 
fee  structure.  TRW  distributes  half  of  the  award  fee  as  bonuses  to 
project  personnel  based  on  merit. 
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Overall  Software  Test  Approach 


•  DETAILED  SRS 
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MITRE 

Two  types  of  formal  tests  are  being  applied  to  each  of  the  CCPDS-R  software 
builds.  Stand-alone  tests  are  performed  on  build  components  to  verify 
satisfaction  of  detailed  Software  Requirement  Specification  (SRS)  requirements, 
such  as  algorithms  (equations,  logic,  etc.)  and  message  validation  (e.g.,  field 
contents).  About  25  percent  of  the  SRS  requirements  are  expected  to  be 
verified  by  stand-alone  tests.  In  addition,  engineering  string  tests  are  performed 
to  verify  satisfaction  of  SRS  end-to-end  functional  requirements,  such  as  ability 
to  receive  a  missile  launch  event  message,  process  it,  and  generate  a  threat  fan 
for  display.  Engineering  string  tests  implicitly  verify  many  detailed  SRS 
requirements  without  the  need  for  detailed  stand-alone  testing.  Approximately 
40-45  percent  of  the  SRS  requirements  are  expected  to  be  verified  by 
engineering  string  tests.  At  the  conclusion  of  the  last  build,  FQT  will  be 
performed  on  the  total  subsystem  software  against  SRS  requirements,  both 
detailed  and  end-to-end.  Actual  FQT  testing  may  be  limited  to  new  functionality, 
implemented  since  testing  of  the  last  build,  and  to  regression  testing  of  changed 
areas.  Other  SRS  requirements  may  be  verified  through  analysis  of  the  prior 
stand-alone  and  engineering  string  test  results  obtained  from  testing  each  build. 
Only  about  30-35  percent  of  the  SRS  requirements  are  expected  to  be 
specifically  verified  at  FQT. 
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Missile  Warning  Software  Coded  vs.  Time 
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This  chart  plots  the  percentage  amount  of  the  Missile  Warning 
Subsystem  software  coded  to  date  as  a  result  of  the  build  process.  At 
CDR,  which  took  place  in  June  1989,  approximately  75  percent  of  the 
software  was  demonstrated.  This  experience  runs  counter  to  the  usual 
case  where  CDR  is  a  review  of  detailed  design  and  the  outcome  of  CDR 
is  approval  to  proceed  to  code.  On  the  CCPDS-R  Program,  the 
Government  specified  that  a  build  approach  was  to  be  taken  throughout 
the  development  cycle.  As  a  result,  reviews  like  PDR  and  CDR  have 
become  the  culmination  of  a  series  of  PDWs  and  CDWs,  respectively. 
Formal  reviews,  like  PDR  and  CDR,  continue  to  provide  an  opportunity 
for  all  parties  to  meet  periodically  to  review  the  progress  made  to  date, 
and  to  participate  in  the  formal  demonstrations  conducted  in  conjunction 
with  the  reviews. 
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SRS  Review  Process  vs.  Build  Demos 
and  Stand-Alone  Tests 
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The  iterative  nature  of  the  CCPDS-R  software  development  extends  also 
to  the  documentation.  The  review  and  approval  process  for  the  Missile 
Warning  Subsystem  SRSs  took  about  two  years  from  receipt  of  early 
drafts  to  readiness  for  authentication.  This  process  included  four  formal 
submittals  of  the  SRSs  prior  to  CDR,  each  with  a  review  and  comment 
resolution  cycle.  The  SRSs  were  first  placed  under  TRW  configuration 
control  in  May  1 988  as  a  prerequisite  for  conduct  of  the  first  formal 
stand-alone  tests.  They  remain  under  TRW  configuration  control  and 
are  not  expected  to  be  authenticated  (i.e.,  put  under  the  Government's 
configuration  control)  until  shortly  before  FQT. 


Software  Reuse  (Case  1 ) 


225K 

TOTAL 


34.0%  REUSED/MODIFIED 
38.2%  NEW 

27.8%  TOOL-GENERATED 


This  chart  depicts  TRW's  current  projection  of  software  reuse  in  which  a 
total  of  21  OK  SLOC  are  reused  from  the  development  of  one  CCPDS-R 
subsystem  to  the  next.  Due  to  similarities  between  portions  of  the 
Missile  Warning  Subsystem  and  Missile  Warning  Displays  Subsystem, 
an  additional  35K  SLOC  can  be  modified.  This  results  in  about  34 
percent  of  the  total  720K  SLOC  being  reused  or  modified. 
Approximately  28  percent  of  the  CCPDS-R  software  is  expected  to  be 
generated  by  tools. 
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Software  Reuse  (Case  2) 
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A  second  scenario  is  depicted  on  this  chart  which  assumes  the  existence 
of  additional  tool-generated  code  in  the  same  proportion  as  for  the 
Missile  Warning  Subsystem  (Case  1).  Under  this  case,  the  same 
amount  of  code  (245K  SLOC)  is  reused  or  modified.  However,  the 
percentage  is  reduced  to  20.2  percent  due  to  the  increased  total  code 
(1215K  SLOC).  In  either  absolute  terms  or  as  a  percentage  of  the  total 
software,  the  amount  of  projected  reuse  is  not  insignificant. 
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The  amount  of  reused/modified  code  coupled  with  the  large  amount  of 
tool-generated  code  is  enhancing  TRW's  software  productivity, 
measured  from  Contract  Award  to  FQT  of  the  third  subsystem.  Current 
estimates  range  from  a  low  of  5.4  SLOC  per  staff-day,  if  labor  credit  is 
given  to  "new  code  only,"  to  a  high  of  14.2  SLOC  per  staff-day,  if  all  code 
is  equally  weighted  with  respect  to  the  amount  of  labor  needed  to 
produce  it.  The  true  productivity  is  somewhere  in  between.  Linder  one 
scheme  where  tool-generated  code  is  weighted  at  1 0  percent  of  the 
labor  required  for  new  code,  the  productivity  figure  is  6.6  SLOC  per 
staff-day.  Under  another  in  which  tool-generated  code  is  weighted  at  60 
percent  (per  most  recent  TRW  data),  the  productivity  figure  is  8.6  SLOC 
per  staff-day.  By  any  measure,  the  productivity  is  very  good  due  largely 
to  the  staffing,  schedule,  prototyping,  and  build  process  considerations 
cited  previously,  in  addition  to  the  enhanced  interface  discipline  imposed 
through  the  use  of  Ada,  the  flexibility  of  TRW's  message-based  design, 
and  the  development  of  the  most  dificult  foundation  software  first. 
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Tool-Generated  Ada  Source  Code 


Approximately  1 5K  SLOC  of  tool  software  is  responsible  for  generating 
over  200K  SLOC  of  compilable  Ada  source  code  --  a  13:1  expansion 
ratio.  The  existence  of  this  tool-generated  software  has  been  and 
continues  to  be  a  problem  area  for  the  Government  on  the  CCPDS-R 
Program.  First  of  all,  this  software  was  not  anticipated  at  the  time  the 
CCPDS-R  Program  was  formulated.  As  a  result,  the  Government  has 
little  visibility  into  this  area.  Issues  such  as  tool  design  documentation 
and  test  of  the  tools  are  not  addressed  contractually.  Yet,  the  code 
generated  by  the  tools  represents  anywhere  from  28-57  percent  of  the 
total  CCPDS-R  software.  Secondly,  the  tools  which  TRW  has  found 
necessary  for  development,  will  probably  be  needed  by  the  Government 
for  software  maintenance.  Provisions  for  user's  manuals  addressing  tool 
parameters  (legal  values,  capacities),  rules  for  use,  and 
interdependencies  between  files  remain  undefined.  The  Government  is 
working  diligently  with  TRW  to  resolve  these  two  areas  of  concern. 


Flexible  vs.  Tailored  Designs 
for  Missile  Warning  Subsystem 
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This  vugraph  compares  the  software  size  and  CPU  utilization  associated 
with  the  TRW  Missile  Warning  Subsystem  design  against  estimates  for  a 
tailored,  relatively  inflexible,  design  for  that  same  subsystem.  As 
expected,  the  flexible  TRW  design  is  bigger  in  total  size  due  to  its 
general-purpose  nature.  Similarly,  the  CPU  utilization  for  the  TRW 
design  exceeds  that  of  the  tailored  design.  Such  is  the  price  for 
flexibility.  In  the  past,  these  overhead  factors  could  have  been  severely 
limiting  in  terms  of  achieved  functionality  and  quantitative  performance. 
However,  with  the  continuing  rapid  advances  in  processor  memory 
capacity  and  CPU  speed,  TRW  is  demonstrating  that  the  extra  code  to 
provide  flexibility  can  be  absorbed  without  serious  effects. 
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Documentation  Tailoring 
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Despite  the  best  efforts  of  all  concerned  during  contract  definition,  the 
CCPDS-R  Program  is  inundated  with  paper.  Overall,  the  contract  calls  for  a 
total  of  1 ,029  document  deliveries  across  the  three  subsystems.  This  chart 
shows  some  of  that  paper,  much  of  it  driven  by  the  numbers  of  CSCIs.  There 
are  six  CSCIs  for  the  Missile  Warning  Subsystem,  five  CSCIs  for  the  Missile 
Warning  Displays  Subsystem  (not  shown),  and  seven  CSCIs  for  the  Force 
Management/Survival  Subsystem  (also  not  shown).  As  the  Government's  and 
TRW's  experiences  with  the  Missile  Warning  Subsystem  mature,  we  are 
finding  that  fewer  CSCIs  will  suffice  to  provide  the  proper  degree  of  visibility 
and  control.  Accordingly,  for  the  Force  Management/Survival  Subsystem,  the 
Government  and  TRW  are  now  planning  on  a  single  CSCI  which  will  greatly 
alleviate  the  number  of  software  requirements  and  design  deliverables.  In 
addition,  we  are  planning  to  eliminate  the  Software  Detailed  Design  Document 
(SDDD)  as  a  deliverable.  This  is  consistent  with  DOD-STD-2167A.  Neither 
the  Government  nor  TRW  has  found  the  SDDD  useful  for  either  software 
development  or  software  maintenance  because  of  the  high  readability  of  Ada 
code. 
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Software  Progress  Metrics 


•  Software  staffing 

•  Software  size 

•  Development  progress 

-  Design/code/unit  test/document 

•  Test  progress 

-  Integration/component/string  tests 

-  Test  procedures 

-  Requirements  verified 

•  Software  problem  reports 

-  SPRs/SDPRs 

•  Action  items  from  reviews 

-  Monthly/PDW/CDW/demos 

•  Cost/schedule  variances 
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The  CCPDS-R  Program  employs  extensive  metrics  to  manage  the 
software  development.  This  chart  lists  the  major  metrics  reported 
monthly  at  each  Program  Management  Review  (PMR)  and  recorded  in  a 
monthly  software  metrics  report.  Several  of  these  metrics,  such  as 
development  progress,  are  produced  automatically  by  tools  which 
examine  the  Ada  source  code  and  determine  the  state  of  its  completion. 
Notably  missing  from  the  list  of  metrics  is  one  that  deals  with  software 
timing  (CPU  utilization).  In  retrospect,  such  a  metric  based  on 
measurements  (as  opposed  to  modelling  only)  should  have  been 
included  as  a  deliverable.  The  Government  is  currently  working  with 
TRW  to  remedy  this  situation. 


Example  of  Evolving  Task  Level  Software 
_ (PDR  Design) _ 


A  feature  of  Ada  is  that  it  allows  tasks  to  be  defined  at  any  level  of 
functionality.  At  one  extreme,  all  of  the  software  could  be  defined  as  one 
big  task.  At  the  other,  separate  tasks  could  be  defined  for  each  and 
every  function.  In  the  early  phases  of  the  Missile  Warning  Subsystem 
development,  such  as  at  PDR,  the  latter  tended  to  be  the  case.  This 
gave  both  TRW  and  the  Government  visibility  into  and  enhanced  ease  of 
understanding  of  the  software. 
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Example  of  Evolving  Task  Level  Software 
_ (CDR  Design) _ 


As  time  has  progressed,  the  design  has  evolved,  and  in  several  areas 
tasks  are  being  merged.  At  CDR,  for  example,  the  previously  separate 
tasks  (OPCL,  MENU,  and  GEO)  each  of  about  10K  SLOC  were  merged 
into  a  single  new  task  (DISP)  of  about  30K  SLOC.  Reducing  the  number 
of  interdependent  tasks  tends  to  reduce  the  number  of  overhead  calls  to 
VMS,  Starlet,  and  ITC  which,  in  turn,  reduce  processing  time. 
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Pros  and  Cons  of  Merging  Ada  Tasks 


•  Reduces  VMS  and  STARLET  overhead 

•  Improves  response  time  characteristics 

•  Makes  software  maintenance  more  difficult 

-  Small  changes  entail  extensive  recompilation 

-  Software  is  harder  to  understand 


A  balance  needs  to  be  established  between  the  need  to  merge  tasks  in 
order  to  reduce  overhead  and  response  time,  and  the  need  to  design 
software  that  is  both  understandable  early  in  the  development  and 
maintainable  after  development.  The  merging  of  tasks,  which  TRW  is 
undertaking,  to  meet  quantitative  performance  requirements,  may  have 
maintenance  impacts  in  terms  of  compilation  time  and  ease  of 
understanding.  The  Government  is  continuing  to  assess  this  area 
actively. 
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TRW/MITRE  Software  Communications 
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The  final  characteristic  of  the  CCPDS-R  Program,  but  not  the  least  in 
terms  of  impact,  is  the  extensive  amount  of  communication  which  takes 
place  between  TRW  and  the  Government.  These  are  contractually 
established,  and  include  monthly  PMRs,  bi-weekly  Technical 
Interchange  Meetings  (TIMs),  working  groups  in  several  areas, 
PDWs/CDWs,  and  formal  demonstrations.  As  of  August  1989,  more 
than  60  such  exchanges  have  taken  place  on  the  Program,  not  including 
daily  interaction  via  telephone  at  all  staff  levels. 


Risk  Reduction  Summary 

(1  of  2) 


•  Trade  studies 

•  Software  Engineering  Exercise 

•  Software  prototyping 

•  Early  review  of  draft  SRSs 

•  Realistic  schedule 

•  Qualified,  appropriately  sized  staff 

with  core  group  of  experts 

•  Prototyping  &  evaluation  of  high  risk  items 

(algorithms) 

•  Performance  modelling  &  testbed  measurements 

•  Incremental  software  builds 

•  Incremental  software/subsystem  testing 

•  Early  capability  demonstrations 


This  chart  and  the  next  summarize  the  various  risk  reduction  measures 
taken  or  being  taken  on  the  CCPDS-R  Program  dating  back  to  the 
Concept  Development  Phase  when  engineering  trade  studies  and  a 
Software  Engineering  Exercise  were  performed. 
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Risk  Reduction  Summary 

(2  of  2) 


•  Exercise  of  delivered  code  in  local  MITRE/ESD 

testbeds 

•  Software  reuse 

•  Tailored  documentation 

•  Software  progress  metrics 

•  Working  groups 

•  Technical  interchange  meetings 

•  Monthly  contractor  management  reviews 

•  Periodic  Red  Teams/Corporate  Level  Assessments 

•  MITRE  on-site  representative 

•  Direct  comment  processing  (APIS) 


MITRE 


Other  risk  reduction  measures  include  exercise  of  the  TRW  build  code 
locally,  and  independent  audits  such  as  Corporate  Level  Assessments 
(CLAs).  Since  mid-1988,  the  Government  has  had  a  MITRE  (and  a 
CTA)  representative  on-site  at  the  TRW  plant  in  Dominguez  Hills,  CA. 
This  on-site  representation  has  been  invaluable  in  providing  liaison 
between  TRW  and  the  Government,  and  active  Government  participation 
on  TRW  Program  Configuration  Control  Board  (PCCB)  and  Software 
CCB  (SCCB)  meetings.  The  ability  to  electronically  transmit  to  TRW 
Government  comments  on  TRW  deliverables  via  APIS  has  helped  to 
resolve  differences  early. 


Areas  for  Improvement 

(1  of  2) 


•  Improve  knowledge  of  application 

•  Pin  down  requirements  before  going  on  contract 

-  Algorithms 

-  Displays 

-  External  interfaces 

•  Keep  number  of  CSCIs  to  a  minimum 

•  Tailor  documentation  to  reduce  paper  load 

•  Keep  design  out  of  SRSs 

•  Eliminate  software  detailed  design  document 

•  Plan  for  collocation  period  if  geographically  dispersed 

•  Use  graphics  tools  early  in  design  process 

•  Plan  for  documentation  and  review  of 

specially  developed  software  tools 

•  Provide  mechanism  for  modifying  tools  into 

properly  integrated  set 

MITRE 


Notwithstanding  the  progress  made,  this  chart  and  the  next  identify  areas 
of  weakness  on  the  CCPDS-R  Program.  Some  are  too  late  to  remedy; 
however,  where  possible  the  Government  and  TRW  are  working 
together  to  improve  the  situation. 
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Areas  for  Improvement 

<2  of  2) 


•  Quantify  overhead  CPU  usage  of  foundation 

software 

•  Obtain  early  and  continuing  measurements  of 

sizing  and  timing,  and  track  convergence  with 
QPRs 

•  Define  requirements  for  software  maintenance 

early 

•  Assess  evolution  towards  fewer  Processes  and 
Tasks  (in  order  to  meet  QPRs)  against 
requirements  for  flexibility/maintainability 

•  Balance  early  verification  of  requirements  against 
scope  of  regression  testing 


MITRE 


This  chart  concludes  the  listing  of  areas  for  improvement. 
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Factors  Behind  Successful 
_ Software  Development* 

•  Quality  SRSs 

-  Reflect  detailed  understanding  of  job  to  be  done 

-  Contain  testable  req'ts. 

-  Guide  to  software  designers/coders 

•  Quality  test  program 

-  Thorough  &  extensive 

-  Sufficient  staffing  &  computer  resources  to  do  job 

•  Frequent  Contractor/Government  interaction 

-  Close  professional  working  relationship 

•  Contractor/Government  knowledge  of  application 

-  Key  members  experienced  in  application 

-  Key  members  experienced  in  software  acquisition 

•  Continuity  of  Contractor/Government  key  personnel 

-  From  Contract  Award  to  completion  of  testing 

•  Extracted  from  lessons  learned  from  the 
Berlin  Radar  Program,  19dS 


At  the  conclusion  of  the  Berlin  Radar  Program,  which  is  generally  viewed 
as  a  successful  software  development  program,  a  survey  was  made  of 
MITRE  participants  to  identify  success  factors.  The  consensus  is  shown 
on  this  vugraph.  All  of  the  factors,  except  for  knowledge  of  the 
application,  are  viewed  as  strong  features  of  the  CCPDS-R  Program.  As 
noted  on  the  areas  for  improvement  charts,  elements  within  both  the 
Government  and  TRW  need  to  make  continuing  efforts  to  improve  their 
understanding  of  missile  warning,  attack  assessment,  force 
management,  and  force  reconstitution  operations. 
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Conclusions 


•  CCPDS-R  software  development  approach  is  working 

•  New  Ada  technology  is  being  effectively  coupled 

with  the  best  of  lessons  learned  from  the  past 

•  Programmer  productivity  has  been  greatly  enhanced 
through  software  reuse,  isolation  of  difficult  Ada 
features,  and  use  of  tools  to  generate  Ada  source 
code 

•  Useful  and  demonstrable  code  is  available  early  to 
judge  true  progress 

•  Demonstrations  are  invaluable  in  obtaining  user 

input  on  requirements  nuances 

•  Performance,  schedule,  and  cost  objectives  are 

being  met 
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In  conclusion,  the  CCPDS-R  software  development  approach  is  working 
due,  in  large  measure,  to  an  effective  coupling  of  Ada  technology  with 
the  best  of  past  lessons  learned.  It  is  doubtful  whether  either  alone 
would  have  resulted  in  the  degree  of  success  enjoyed  so  far.  Software 
productivity  is  being  enhanced,  demonstrations  are  being  used  as  true 
measures  of  progress  and  proper  interpretation  of  requirements,  and  the 
overall  objectives  of  the  program  are  being  met. 

Additional  data  is  needed  in  a  number  of  areas.  These  include  the 
extent  to  which  code  can  be  reused,  the  degree  to  which  the  TRW  code 
generation  tools  are  essential  for  software  maintenance,  and  the 
trade-offs  between  merging  Ada  tasks  and  software  maintainability. 


GLOSSARY 


ANMCC 

AFB 

APIS 

CA 

CCO 

CCPDS-R 

CDR 

CDW 

CINC 

CLA 

CMP 

COTS 

CPU 

CSCI 

CSSR 

DCO 

DDSI 

DEC 

DISP 

ESD 

FDB 

FQT 

GEO 

H/W 

IOT&E 

IR&D 

ITC 

LAN 

NAS 

NMCC 

NUDET 

OPCC 

OPCL 

PCCB 

PDR 


Alternate  National  Military  Command  Center 
Air  Force  Base 

Automated  Program  Information  System 

Contract  Award 
Common  Communications 

Command  Center  Processing  and  Display  System  -  Replacement 

Critical  Design  Review 

Critical  Design  Walkthrough 

Commander-In-Chief 

Corporate  Level  Assessment 

Common  Mission  Processing 

Commercial-Off-The-Shelf 

Central  Processing  Unit 

Computer  Software  Configuration  Item 

Communications  System  Segment  Replacement 

Display  Coordination 
Digital  Display  System  Interface 
Digital  Equipment  Corporation 
Display  Generation 

Electronic  Systems  Division 

Fused  Database 
Formal  Qualification  Testing 

Geographic  Display 

Hardware 

Initial  Operational  Test  and  Evaluation 
Independent  Research  and  Development 
Inter-Task  Communications 

Local  Area  Network 

Network  Architecture  Services 
National  Military  Command  Center 
Nuclear  Detonation 

Offutt  Processing  and  Correlation  Center 
Operator  Control 

Program  Configuration  Control  Board 
Preliminary  Design  Review 


PDS 

PDW 

PMR 

QPR 

SAC 

SAS 

SCCB 

SDD 

SDDD 

SDR 

SEWS 

SLOC 

SMGR 

SOW 

SRS 

SSR 

SSV 

STLDD 

TAS 

TIM 

USI 

VDSI 

VMS 

WSO 


Processing  and  Display  Subsystem 
Preliminary  Design  Walkthrough 
Program  Management  Review 

Quantitative  Performance  Requirement 

Strategic  Air  Command 
Software  Architecture  Skeleton 
Software  Configuration  Control  Board 
System  Description  Document 
Software  Detailed  Design  Document 
System  Design  Review 
Satellite  Early  Warning  System 
Source  Lines  of  Code 
Screen  Manager 
Statement  of  Work 
Software  Requirement  Specification 
Software  Specification  Review 
Systems  Services 

Software  Top-Level  Design  Document 

Test  &  Simulation 
Technical  Interchange  Meeting 

User-System  Interface 

Visual  Display  System  Interface 
Virtual  Memory  System 

Warning  System  Operator 
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